Especially if it's monitoring the default gateway IP. ISP gateways often prioritise ping replies pretty low. Try setting an external monitoring IP to get a better idea of real connectivity. Steve

@stephenw10 Well, I've just switched to virtio again, rebooted all of them, and it works... weird indeed.

@stephenw10 said in 23.01 - Internal speaker no longer works - "Device "spkr" is Giant locked": The speaker is likely just the last thing it shows and nothing to do with what it's halting on. What image did you use to install from exactly? Does it fail to boot the installer or after installing? You used USB NICs? Steve I've used the USB installer (VGA) build from Pfsense website. It failed at installation part where it shows that error message. I'm not using any USB nics aside from the internal one from the mobo. I'll try to screenshot the whole thing so I can better explain myself .

@stephenw10 thank you.

How exactly does it appear when this happens? Where are you logging in? What is logged when that happens? What pfSense version are you running? Steve

Do you have an old router with a switch in it you could use as a test perhaps? Or maybe you could put the WAN through a VLAN on another switch so it's already linked?

The registration token? No. Once a device has been registered the token is expired and not used anywhere.

Mmm, Realtek NICs can cause problems but link delays are not usually one of them. If Intel NICs work though stick with them. Intel NICs are almost always the best choice.

Cool, if that works for you I would expect any issues. Since you're exporting all the logs you don't need them locally.

The problem was solved with this Patch Thanks to the pfsense Team! (@jimp ) Have a fine Day, fireodo

So clients are unable to resolve anything when this happpens but pfSense itself can? In Diag > DNS Lookup?

I've installed a fresh 2.7 and the issue is gone now. Can be closed. Thank you

So rotate logs on a schedule rather than a maximum size? And copy the log files out before doing that? There's nothing built in to do that. You'd probably want to write your own newsyslog conf file and call it from cron.

SOLVED I discovered that if I put the config (both in the root and in \config) on my boot installer, which had the 64MB PFSENSE FAT32 partition, the ECL worked correctly. So, I reformatted the USB drive I was working with as a 64MB FAT32 partition (named PFSENSE) and wala, success! Previously, the USB drive was formatted to use the entire drive of 4 GB. No idea why reformatting it to a smaller size matters... But, in case anyone else runs across the same problem...

Yup, those devices are probably not trying to resolve .local addresses using DNS servers at all. They assume they are mDNS and try to find them locally.

As no one official has acknowledged the bug yet - just wanted to report it running like this on a customer's box that needed it urgently and since implementing the fix 2 days ago, it still works without anything bad breaking or anything.

@stephenw10 said in 23.05.01 can't normal boot: 23.05.1 The pf v23.05.1 version will have this problem when the system starts. Other pf versions do not have this problem when the system starts. For other pf versions, this problem will occur after the system has been running for a period of time

@NollipfSense I will do the clean install. THANKS!

@yjd said in Lan's ip is 254, and the web page cannot be accessed: reason is that I believe too much in the privacy mode of the browser, so I did not try to change ie and firefox for testing. Strange. We use different info sources then. I would prefer Firefos far over edge or the chrome thing. The last two have just one main mission : transmit everything you do to their creator. Showing a web page is their second role @yjd said in Lan's ip is 254, and the web page cannot be accessed: disable and re-enable the network card during the test Always check afterwards your DNS/gateway IP. You can stop checking as soon as you're done designing your network. @yjd said in Lan's ip is 254, and the web page cannot be accessed: I usually give priority to clearing the cache and testing again. . . If you visit a web page on 192.168.1.1 (so 192.168.1.1 is the URL) - and then you visit a device at 192.168.1.254, then there will be no cache involved, as it is not the same device neither the same web server (in theory - this time it is, as you've changed the IP of the web server device). @yjd said in Lan's ip is 254, and the web page cannot be accessed: to clearing the cache Remember this one : ipconfig /flushdns

@Yet_learningPFSense said in There were error(s) loading the rules: /tmp/rules.debug:25: cannot define table: @rcoleman-netgate It was about two months ago that I set up PFSense myself, using version 2.6.0 of PFSense and installing pfBlocker about a month ago (I didn't note down the version). There might have been some issues due to the version mismatch. I am currently using the latest version of PFSense, which is 2.7.0.